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ABSTRACT 



World Wide Web authors are often tempted to use the latest 
and sexiest means to present their information. "Hot" and "cool" sites use 
dancing graphics, frames, tables, specific fonts, and background and 
foreground colors to entice the reader and delight the eye. Sound clips often 
convey emotional content that cannot be expressed in text, and digital video 
clips present movement. However, the use of these means tends to 
disenfranchise some users. It is important to consider potential users’ 
limitations, and make information accessible to all. Deaf readers need text 
support for sound clips, as well as visual clues to any audio stimuli, 
including beeps and bells. Blind readers need to be able to access the 
information content through text presented in a linear manner, so that it can 
be rendered as sound through their specialized equipment. Readers at the end 
of a telephone line need access to the information content even when they 
turn off the display of online images, and readers with older computers need 
pages that work with a text browser, such as Lynx. This paper describes 
hypertext markup language (HTML) coding techniques to enhance accessibility 
without totally forsaking attractiveness. The paper is intended for Web 
authors who can understand HTML tagging without lengthy explanations. 
(Contains 15 references.) (Author/SWC) 
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Web authors are often tempted to use the latest and sexiest means to present their 
information. "Hot" and "Cool" sites use dancing graphics, frames, tables, specific fonts, 
background and foreground colors to entice the reader and delight the eye. Sound clips 
often convey emotional content that cannot be expressed in text. Digital video clips are 
jerky but they do move. 

This tends to disenfranchise some users, however. When we put up web pages to provide 
information to our clientele, we need to remember their limitations, and make our 
information accessible. Deaf readers need text support for sound clips, as well as visual 
clues to any audio stimuli, including beeps and bells. Blind readers need to be able to 
access the information content through text presented in a linear manner, so that it can be 
rendered as sound by their specialized equipment. Readers at the end of a telephone line 
need access to the information content even when they turn off display of inline images, 
and readers with older computers need pages that work with a text browser, such as Lynx 

The presentation will demonstrate HTML coding techniques to enhance accessibility 
without totally forsaking attractiveness. The potential audience will be web authors who 
can understand HTML tagging without lengthy explanations. 

Audience. 
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Writing HTML for accessibility differs according to the needs of the audience. While 
many of my suggestions are applicable across the board, there are some considerations 
that apply particularly to specific groups of users. 
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Blind readers. 

The usual coping mechanism for blind readers of computer screens is to use a screen 
reader program to render the text of the screen as speech with a speech synthesizer or in 
Braille with a refreshable Braille display. (PacieHo) The speech synthesizer may be 
standalone hardware, such as DecTalk, or software used in connection with a standard 
sound card, such as TextAssist, which comes bundled with SoundBlaster cards from 
Creative Labs. 

Screen readers do a pretty amazing job of translating the characters on a screen, reading 
from left to right and top to bottom, into phonemes which are spoken by the hardware. 
Most screen readers take total control of the hardware, however, and override the 
possibility of playing embedded sound files through the sound card. A specialized web 
page reader, pwWebSpeak . overcomes this limitation. Pages designed to be taken in at a 
glance, using colors and type sizes to draw the eye to particular parts, take on a whole 
new "look" when read aloud serially. 

Deaf readers. 

Web pages are mostly accessible to deaf readers. Audio clips are an obviously 
inaccessible element. Some of the sound cues provided by web pages and web browsers 
should be reinforced with visual cues. Windows 95 has accessibility options, including 
SoundSentry and ShowSounds to accommodate deaf users. SoundSentry is available for 
Windows 3.1 as part of the Access Pack at 

http://www.windows.com/windows/enable/accessw.htm by mail or FTP. 

Many hearing readers have non-speaking computers (no sound cards). Both deaf readers 
and these impoverished souls (including most users of Library computers) are helped by 
web authors who include a text alternative, or at least a description, for each audio clip. 

Poor readers. 

Not everyone can have the latest Intel and Microsoft wallet-shrinking toys. Many of our 
readers make do with slow modems, and turn off automatic loading of images. Freenets 
and low-end Internet service providers supply UNIX shell access to the WWW with Lynx 
text-only browsers. Most third world access to the Web is through such narrow pipes. 

Webmasters who count access by browser type cite low percentages of Lynx users as 
justification for using the more resource intensive HTML features. This smacks of the 
self-fulfilling prophecy; who would visit www.sears.com a second time with Lynx or 
with images turned off? In a recent exchange on the web-consultants discussion list, 
Gregory J. Rosmaita, under the pseudonym Oedipus wrecked, suggests that the number 
of non-graphic browser users is understated: 

even a cursory glance at the lynx-dev mailing list's hypertext archives would 
reveal that, currently, there are Japanese, Chinese, Egyptian, Turkish, 

Brazilian, American, Canadian, German, Swedish, Ukranian, Russian, and a 
host of other programmers working on national charsets, libraries, and 
patches for lynx... if lynx's user base was as small as is claimed on this list, it 
would have breathed its last with the release of 2.4.2 ( Gill . The Web: Design, 
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ADA and Lynx) 

Practicalities. 

This section will present specific suggestions for improving HTML with an eye to 
accessibility by all the audiences explored above. 

Compatibility. 

What works in Lynx will work in all other browsers; the converse is not true. Designing 
for Lynx requires clean HTML 2.0 code; providing alternatives for blind and deaf users 
also accommodates readers without disabilities who have diverse learning styles. For 
example, a .jpg image of a medieval manuscript is visually impressive, but inaccessible to 
a blind reader. Provision of a transcribed text not only allows the blind reader access to 
the content on one level but also provides the sighted reader with a key to deciphering the 
text, which is likely to be full of medieval abbreviations. 

Many Web authors do not know the differences among the HTML standards, and may 
not realize how badly the pages they write with WYSIWYG editors may present 
themselves in diverse browsers. Gerald Oskoboiny does us all a great service with his 
"Kinder, Gentler Validator" at http://ugweb.cs.ualberta.ca/~gerald/validate/ where he 
offers HTML grammar checking and Weblint style analysis. If you submit a page without 
a <!DOCTYPE> declaration it will be parsed at HTML 2.0 level and the information that 
Gerald makes available will teach you much about the various flavors of HTML. 

Oskoboiny also provides a way to see approximately how your pages would appear in 
Lynx without launching a Lynx browser, http://ugweb.cs.ualberta.ca/~gerald/lynx-me.cgi 
is the address; this is actually a script that requires a URL as an argument, but try the 
address given to get further instructions from Gerald directly. 

Images. 

No <img> tag should be published to the world without the alt=" " parameter. (Fontaine ! 
For images that contribute content to the document, provide a concise description, 
preferably within square brackets, since Lynx users associate square brackets with 
images, usually in the useless form [image] or [inline]. For example <img src- 'paul.jpg" 
alt="[Paul]" width=44 height=60> would alert the user that there is a picture of Paul 
available. Inclusion of the width and height attributes does nothing for the Lynx user, but 
does save the time of the graphic browser user, since the browser can reserve a space 44 
by 60 pixels and continue to display text without having to stop and retrieve the image 
from the server to take its measurements. 

Text expressed not in ASCII characters but as part of an image, often in a banner or 
letterhead image, must be expressed in alt="the words in the image" to avoid losing 
content without the image. 

Larger images should be presented in thumbnail versions, with a link to their larger selves 
to be loaded on demand. The link text would include the thumbnail image itself and an 
indication of its approximate size in kilobytes, as in this example: <a 
href="asiamin.gif'><img src="asiamic.gif' width=44 height=26 alt="[Map: Asia 
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Minor]"> 47K</a> The full-size image will be loaded as a separate page if the link is 
selected by the user. Since it stands alone, no provision for including its width and height 
is needed. 

An image editor, such a LviewPro or Photoshop, can easily create smaller versions of .gif 
or .jpg images for use as thumbnails. It is also possible to use the same file for both, with 
the width and height attributes used to tell the browser to reduce the image size on the fly, 
but this means asking the user to do with each load work that can be done once only. This 
is a blatant violation of Ranganathan's fourth law of library science, "Save the time of the 
Reader." 

Images that are purely decorative, contributing to the look of the graphic page but useless 
to the non-graphic browser user, can be hidden from the latter's sight or hearing by using 
the alt= parameter to make the alternative text a null or empty string: <img 
src="wavyline.gif' width=480 height=5 alt=""> Note that there is absolutely nothing 
between the quotes. 

Image Maps. 

Graphic designers love them, HTML writers are pleased as punch to make them work at 
last, but ISMAP images are absolutely useless to readers without graphics. For these 
users we need to provide either a link to a text-based alternate page or a set of text links 
in the page with the map itself. My preference is for the latter approach, with the image 
map carrying a null string as alternative text, lest a user select it as a link without any 
coordinates. (Fontaine) 

Buttons. 

Some page designers seem to resent the conventional look of link text in bright blue with 
underlining, preferring to use buttons as link images. They often add the border=0 
parameter to the <img> tag to prevent the blue border that indicates a link. When they 
provide alternate text for the buttons it is likely to be alt-'*" which creates a bit of a 
mystery for the Lynx user reading the page with a screen reader and a voice synthesizer. 
These pages can also be mysterious to sighted users with graphic browsers, unless they 
are savvy enough to notice that the cursor changes shape when poised over a link image. 

My preference is to use link text in association with images that suggest the target, if 
appropriate. I welcome the blue border and the bright blue underlined text convention that 
gives the user belt-and-suspenders assurance that this is indeed a link. 

"Click here". 

One way to avoid the "click here" syndrome, is to test pages in Lynx, which does not 
click at all. Link text should express concisely what the user will reach by selecting the 
link. A list of link text items should sound like an invitation to content, not a litany of 
"here, here, this, here, this, here" and "click me." (' Fontaine ! 

Audio. 

Links to audio clips should be accompanied by alternative links to text of an 
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announcement, lyrics of a song, or a description of the sounds that would be heard if the 
user could hear them. For example, it would be delightful if The Capitol Steps 
( http://www.capsteps.comA would provide a link to the script for Lirty Dies: Graberdeen 
Grooving Pounds as well as links to the .au and RealAudio formats of the monologue. 

Linking to a site that automatically starts playing a tune can be quite disconcerting on a 
browser that cannot play the tune; an error message is likely to pop up in the user's face. 
One such is the satiric http://www.highersource.org/ site (not to be confused with the 
.com site), which plays the theme from M*A*S*H ("Suicide is Painless") as background. 

Other formats. 

Just as it is helpful to provide a text alternative to an audio clip, providing either a text or 
an HTML alternative to a .pdf file is a lifesaver to readers who cannot see or display these 
Adobe Acrobat pages. ( Fontaine ) 

Not all browsers can handle forms. If you are really concerned about giving the reader a 
means to provide information to you or your organization, provide alternatives. Many 
sites give users a choice among: 

* an online form; 

* a text form that can be downloaded, filled in, and returned by e-mail or snail mail; 
or 

* a telephone number to call. 

While it is beyond the scope of this paper, when possible moving pictures may be made 
accessible by adding captions in text or in ASL and by providing a descriptive soundtrack 
for blind users. If such options are available, they should probably be provided in 
side-by-side alternative links, rather than included in the only copy of the movie 
provided. ( Vanderheiden ) 

Lists. 

Lists are pretty straightforward HTML elements, but there are a couple of hints that will 
improve accessibility of lists: 

* if using graphics as bullets, provide alt- or alt- 'o" parameters in the <img> tag. 

* include closing punctuation on list items, even if thb items are not grammatical 
sentences, for the benefit of users with screen readers rendering either speech or 
Braille. 

Closing punctuation (full stop or period) is nearly invisible in lists, but looks a little silly 
on headings, but it makes a big difference in how the headings sound with a screen 
reader. Did you really notice the periods in the headings in this page? 

I also added a <br> tag at the end of almost every URL that was expressed as such in the 
text. This really helps clarify to the hearer that the end of the link has been reached, 
especially when the speech synthesizer tries to interpret and pronounce the "words" in the 
URL; for example, the synthesizer reads the "ca" in ugweb.cs.ualberta.ca as "California." 
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Tables. 

From an accessibility standpoint, concern for users with screen readers suggests a "just 
say no" policy. Screen readers read the screen line by line, an approach which creates 
chaos when it encounters even a relatively simple table or columnar arrangement of data. 
Try reading the following table in a line-by-line fashion: 



Table type 


Results in Lynx 


Screen reader results 


preformatted text in 

columns and 

rows 


spacing of the original 
text is preserved in 
fixed spacing typeface 


line-by-line reading does 
violence to the logic of 
the text arrangement 


<table>standard table 
construction</table> 


all table-related tags are 
ignored, text is 
presented in a blob, line 
by line ignoring line 
ends 


same as above 


standard table construction with 
<br> tags at end of each cell 


table-related tags are 
ignored, but <br> tags 
cause new line starts; 
significance of headings 
is lost 


if screen reader is reading 
Lynx screen, new line 
indicates new topic, but 
logic of columns may not 
be obvious 



An appropriate use of preformatted text may be seen in my personal home page at 
http : It www , csun . edu/~mreagan/ where I include the .sig block that I use in electronic 
mail as a concise way to display address and telephone numbers. It is a two-column 
presentation that does not lose too much when read line by line: 



Michael Reagan KK6WO 
mreagan@csun . edu 

(818) 677-4391 fax (818)677-4136 

home (818) 449-0996 fax 449-0952 
pager (818) 828-1226 

-- -- . de gustibus non est 



Circulation Unit Coordinator 
University Library 
California State University 
Northridge CA 91330-8327 
packet KK6WO@W6VIO . #SOCA. CA. USA 
disputandum - 



The roster of the CSU, Northridge Faculty Executive Committee is an example of the use 
of table logic with <br> tags to make it work in Lynx. Its URL is 

http://www.csun.edu/~fs20469/execom.html and it has an extra <br> tag in the right-hand 
cells to create vertical white space between entries when displayed in Lynx. 

Frames. 



Like many of the participants in the web41ib discussion list, I have seen few examples of 
the use of frames that justify the grief this feature causes to the disenfranchised user. 
Lynx cannot handle frames, screen readers balk at them, older browsers stop in their 
tracks. 

If you do feel a need to use frames logic, create the page without it as well, and include a 
link at the top of the frames page to let your readers get to the non- frames version. Do 
this for every page on which you use frames. If you are within the range of normally lazy 
humanity, you will stop putting yourself through the agony of writing the frames version. 
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If your WYSIWYG HTML tool insists on writing with frames, throw it out. 

Applets. 

The arguments above about frames apply in spades to Java applets. They are potentially 
quite powerful, but address only the "rich, well-born, and able" browsers running in 
32-bit operating systems. The World-Wide Web is still predominantly a 16-bit world, 
with huge installed bases of Windows 3.1 machines. Java makes perfect sense if you are 
selling a product to Sharper Image customers, or if you are addressing an Intranet running 
only Windows 95 or Windows NT or PowerPC Macintosh machines. 

Microsoft ActiveX has most of the same disadvantages as Java plus a reputation for 
creating security problems that has many users refusing to allow it. 

Limited video. 

Be kind to your less well-endowed readers when including images in web pages. Some of 
us have video cards with extremely limited memory, so the precise shade of off-mauve 
that best sets off your page featuring a true-color photograph of your award-winning 
black and white Dalmatian is likely to show up as a deadly drab dithered dot design. 
Limiting backgrounds to standard colors, and images to a small palette will produce more 
uniform results across the user base. 

My graphic editor is the freeware LviewPro. When I open an image file the upper border 
displays the file name and its three dimensions, width in pixels, height in pixels, and 
number of colors in the palette used. It is amazing how much difference can be made in 
the size of the image file by reducing the number of colors used. A scanned image of a 
postcard printed on a wood-grain background was 62,151 bytes in .jpg format. As seen in 
an experiment with LviewPro at http://www.csun.edu/~mreagan/images.html the size was 
reduced to 30,569 bytes by limiting the number of colors, and further reduced to 18,345 
bytes by saving it in .gif format. Choosing a reduced file size, if the image quality is still 
adequate, "Saves the time of the Reader." 

Smaller image sizes help keep the total page size within reason. Pages larger than 5 OK to 
75K total should be scrutinized carefully. Many readers will hit the stop button rather 
than wait to see large pages. ( Gill . Issues) 

<Blink>. 

Don't. 

Many users are annoyed by blinking text and animated .gif images, but a few could be 
injured by them. Some epileptic seizures are triggered by pulsing light. Blinking text is 
pulsing light. Need I complete the syllogism? 

Screen readers used to translate text into speech or Braille are usually stymied by blinking 
text, making it impossible for the user to read the rest of the screen. 




Just don't. 
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Futures. 

A simple change of habit will help avoid a "Y2K" problem on web pages. What date is 
01/02/03 on the World-Wide Web? Taking the time to write January 2, 2003, 1 February 
2003, or 3 February 2001 will avoid confusion. ( Starling ! 

Screen readers of the future, optimized for HTML, are likely to do a better job of 
expressing <strong>, <em>, <cite>, or <var> than <b> or <i>. ( DO-IT 1 

A Homily. 

As if I haven't been preaching throughout this paper 

Appearances. 

Much effort is successfully employed in creating printed advertising with the most 
appropriate type faces in exactly the right sizes, custom artwork rendered just so, 
perfectly placed illustrative material, and all the tools of subliminal seduction marshaled 
to engage the intended audience. The obvious potential of the World-Wide Web has 
tempted many to bring their advertising toolbox to this new medium. Some Web authors 
have gone to great lengths in their attempts to control presentation, even including 
tailored quantities of invisible single-pixel .gif images to force the spacing of text on a 
web page. 

Yet, HTML is a Markup Language. It is designed to separate content from 
specific presentation of information. It expects the designer to indicate 
sentences, paragraphs, etc. in a simple way to format clear text. Yet many 
page designers, in an effort to create a "magazine on the screen," have 
resorted to clever techniques to extend the range of HTML. They endeavor to 
force the browser to "display" that information in a specific way— a method 
which may exactly match the format which the designer might pick if he/she 
had complete control. ( Murphy ) 

This effort is doomed to failure, because the balance of power in the Web is shifted away 
from the page producer. The look and feel of a web page is determined by three elements: 

1 . The internal logic of the browser client software has primary control. Pages will 
look different on PCs and on Macintoshes. Netscape, Mosaic, and Internet Explorer 
all have different approaches to display, both among themselves and between their 
own versions. Lynx obviously does things differently. 

2. The browser options selected by the user are secondary but powerful. Whether as a 
matter of taste or as a matter of necessity, users are likely to choose different base 
typefaces and font sizes, monitor resolutions, and background colors, and make 
such basic decisions as whether to allow loading of images or to override page 
preferences with their own. 

3. The choices coded by the Web author are tertiary. 

Since control of the output is futile, you can afford to make your pages as widely 
accessible as possible and embrace the 
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KISS principle (keep it simple, stupid). 

* Focus on content. 

Use tagging that makes the content clear to the widest possible audience. 

* Embrace the conventional - bright blue underlined text is unmistakably a link. 

* Use "sexy" features, bells and whistles only if delivery of the content requires them 
and limited accessibility is acceptable. 

Allow exceptions. 

Not every page can be usable in Lynx. The images.html page referenced above is 
readable in Lynx, but the essential information simply cannot be conveyed without 
graphic capabilities. A page on leitmotifs in Mozart is likely to require audio clips and 
.pdf scores. The reference desk schedule at CSU, Northridge is much clearer and easier to 
maintain in <table> format, and its limited audience is all adequately equipped to handle 
tables. Life writing web pages with an accent to access need not be drab. 
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